alternative_right shares a report from 404 Media: Amazon is buying massive quantities of books, scanning them for AI training data, and destroying them in the process. A 404 Media investigation was able to reveal Amazon's book buying operation, which hasn't been previously reported, by placing a tracking device in a rare book we suspected would be acquired by an AI company for training data, and following it around the country to its final destination. That final destination was an Amazon warehouse in Las Vegas, Nevada. Amazon employees who work at this location say all they do is receive massive shipments of printed books which they then cut the bindings off in order to scan the books more quickly. The printed book is destroyed in the process. The logo of the Amazon team that works at this warehouse, called VGT3, is a dinosaur, brandishing its teeth and with a book in its hands. "Amazon purchases books through commercial channels to help develop and improve the products and services our customers use," an Amazon spokesperson told 404 Media in a statement.

Read more of this story at Slashdot.

Some take their criticism even further. Reacting to Flock's changes, an EFF statement calls it "Too little, too late," while calling it Flock's admission that their technology needs reforms. But... To be clear, our position has long been that police, at a minimum, need to get a warrant, signed by a judge, in order to search for historic ALPR data regarding specific vehicles. For us, it's common sense: if police want to dip into historic ALPR data like they were going back in time to retroactively follow your comings and goings, they need a warrant. There's also nothing stopping Flock from rescinding these latest reforms. This all leads to the bigger and more important issue: We should not be letting companies decide how much privacy we deserve... It shouldn't be up to Flock or any other ALPR vendor to decide how long police can collect and retain data on millions, if not hundreds of millions, of innocent people. We need lawmakers to step up and pass laws that restrict police's use of surveillance technology. After all, the surveillance business model is the problem, and a few company-imposed slapdash reforms aren't going to change that.

Read more of this story at Slashdot.

While Flock announced changes for its AI-powered traffic cameras, "Several of the proposed changes Flock is touting are merely retreads of previous ," complains the American Civil Liberties Union. "Flock's latest announcement still appears more focused on addressing a perceived PR problem than the significant harms its products create... [T]his is hardly the step forward Flock wants us to think it is " The ACLU continues to urge that default retention periods be shortened to 48 hours — not one week. And they warn Flock allows longer retention to any police department that asks for it, or when police officers activate "Evidence Mode" (the scope of which is not yet clear): Even if "Evidence Mode's" data retention hold only applies to hits returned on a given search, it would still retain significant amounts of location data on persons and vehicles who law enforcement do not suspect have engaged in any wrongdoing... Flock claims that its changes will provide "more local control," meaning local police can decide what types of offenses other Flock customers can search their data for... This is not new. Flock has attempted this before, and the security measure failed because users were easily able to circumvent the system's requirement that police input the purpose of their search. For example, on June 12, 2025 Flock started claiming its new "Proactive Search Term Tool" would block any "impermissible" searches, such as abortion-related searches in states like Illinois that prohibit sharing reproductive healthcare data. But police officers quickly realized they could just input "investigation" or even "hehehe" as a search reason and it would be approved. Flock later switched from an open text box to a drop-down menu of reasons, but that just offered police a list of acceptable purposes they could choose from, whether it was accurate or not. Until Flock demonstrates they can develop a reliable, workable system to prevent improper searches, this promise of local control provides nothing more than a false sense of security... While providing "Audit Assistance" to all departments makes sense, there is no evidence that the tool works consistently to address what the Washington Post observed is a growing pattern of police officers turning Flock into a personal stalking tool. While dozens of officers have recently been arrested, fired, or otherwise disciplined for misusing Flock for personal reasons, Flock claims these arrests are proof its auditing tool works. However, unless we know the number of officers misusing the system, we cannot conclude if Flock and its auditing tools are catching 95 percent of violators or 5 percent. Flock needs to have its auditing tool analyzed by an independent evaluator to determine its actual effectiveness. Until then, we don't know if the tool is a real security measure or just window dressing. Perhaps the oddest part of Flock's announcement is its claims that "now every search will require" police to input a case code... While claiming that a "search without a reason is a search that shouldn't happen in the first place," Flock's announcement fails to note how easily users have circumvented "search reason" security measures in the past... This leaves the public wondering how making an ineffective voluntary security measure mandatory will improve its functionality. Flock's "nearly $1 billion in venture capitalist funding has locked it into an operational model that seeks to trade our privacy for massive profits," concludes the ACLU's statement, as they promise to continue "The ACLU is fighting alongside communities to cancel local ALPR contracts and push lawmakers to protect our rights from this surveillance nightmare..."

Read more of this story at Slashdot.

When Anthropic instructed three agents to migrate a Python backend, but telling each agent to perform the migration in a different language, "We consistently saw a multiagent turf war," they wrote Thursday: All of the models we tested quickly assumed that others were purposefully impeding their work, and began to sabotage others while protecting their own contributions. In fact, they sabotaged others with increasingly aggressive, self-replicating malware. This included disabling the Unix accounts of the other agents, writing automated scripts that found and killed competing processes on a loop, and deploying malicious code that was disguised as belonging to another agent. In many runs, one agent settles the conflict by force via access-revocation (e.g., sudo/group removal, account lock, nologin, SSH denial). In others, some agents settle into passivity: they give up and refuse to escalate further. Agents sometimes manage to communicate their goals and coordinate: they recognize others' motivations as conflicting directives rather than hostility, and subsequently break out of the conflict loop in order to stop escalating indefinitely. In many of these successful episodes, they write commit messages or markdown files apologizing for malicious behavior and coordinate a truce. They clean up their malicious code, clarify the nature of the conflict, and ask for a human to intervene... In several episodes with Mythos 5, we observe an emergent behavior where the agents propose and run a tournament for application performance in each language. In the example above, the Rust agent strategizes about bake-off metrics that appear neutral enough for the others to agree to this mechanism, yet would likely favor Rust: one thinking trace warns to be "careful not to be seen as metric shopping". Ultimately, the Golang/TypeScript losers gracefully concede codebase ownership to the Rust agent, giving up on their original user directives under their self-negotiated commitment device. One problem is that AI agents do reward hacking, Anthropic notes, while current institutions "are designed by and for people, resting on assumptions about the sufficiency of oversight at human speed... As autonomous agents become more and more prevalent in the world and operate in ever-more demanding settings, it is crucial that they learn how to effectively coordinate." In addition to everything else, the agents struggled with a lack of clearly defined hierarchy, Anthropic points out. "Nothing above suggests that these failures are permanent — but nothing suggests they will fix themselves, either..." They argue a fix "takes two forms: environments that exert the kinds of social pressure that evolution exerted on us, and social computing systems redesigned for actors that can self-replicate and self-improve. These are open problems in interaction and mechanism design, and our experiments here provide early evidence that new solutions are necessary." "The AI models being tested in this case were Sonnet 4.6, Sonnet 5, Opus 4.6, Opus 4.8, Mythos Preview, and Mythos 5," notes Business Insider, adding that Sonnet 4.6 and Opus 4.6 "were the most combative, settling about 60% of their runs by force instead of truces or passivity." Anthropic argues there's a clear case for researching this phenomenon — especially since "The volume of agent-agent interaction could plausibly exceed that of human-human and human-agent interactions before the world understands the conditions for making such interactions go well."

Read more of this story at Slashdot.

President Trump was sued by nonprofit news groups today over Truth Social's "Truth API" that sells real-time access to posts from Trump and other top users of the social network. Trump is profiting from selling preferential access to government information, the lawsuit said.

Trump's social media company this month started charging customers up to $100,000 per month for the earliest access to posts that can have immediate impacts on financial markets. The first customers are mostly high-frequency trading firms that could benefit financially from getting official government news milliseconds before others.

"This scheme is profoundly corrupt. The President stands to gain financially by giving 'market-moving' government information to those who are willing and able to pay his personal company," the lawsuit said.

Truth Social also intends to impose restrictions on web scraping tools and make its API the only way to access archived posts that have been deleted or edited, the lawsuit said. The lawsuit was filed by The Intercept and the Freedom of the Press Foundation, which argue that Trump is violating the US Constitution by preventing equal access to government announcements.

“A president selling priority access to news he himself generates for the benefit of a private company he controls is so blatantly corrupt and unconstitutional that it would have been hard to even fathom just a few years ago,” said Seth Stern, the Freedom of the Press Foundation's chief of advocacy.

Trump "privatizing government information"

The lawsuit was filed in US District Court for the Southern District of New York. It asks the court to declare that posting official government information exclusively on Truth Social while charging for fast access through the API is unconstitutional and unlawful. It seeks an injunction prohibiting the president and aides from posting official government information exclusively on Truth Social as long as the platform maintains the paid API.

“Trump is trying to enrich himself by privatizing government information that he has no right to sell,” said Ben Muessig, The Intercept's editor-in-chief. “We won’t let it stand.”

Trump frequently posts official government announcements exclusively on Truth Social, including military attacks and ceasefires, the hiring and firing of agency heads, and major domestic policies, the lawsuit said.

“Trump’s crooked scheme is particularly outrageous because, as documented by our Trump Anti-Press Social Media Tracker, he frequently uses his Truth Social account to berate journalists and even to announce his plans to sue them and criminally investigate them," Stern said. "Then, he makes them wait in line behind paying customers to find out about it unless they’re willing to subsidize the platform he uses to attack them. This brazen grift targets not only the markets but the First Amendment."

Truth Social seeks more customers

Besides Trump, defendants include Executive Assistant to the President Natalie Harp and Deputy Chief of Staff Daniel Scavino. Both Harp and Scavino have access to Trump's Truth Social account and publish posts on his behalf, the lawsuit said. The other named defendants are the Executive Office of the President and the White House Office.

Trump Media & Technology Group, the owner of Truth Social, reported $1.7 million in revenue and a net loss of $238.1 million in the second quarter. The net loss included $190.4 million in "non-cash losses including unrealized losses on digital assets, digital assets pledged, and equity securities," the company said.

Trump Media expects that Truth API will help generate more cash. Interim CEO Kevin McGurn said in an earnings call that the firm signed up over 10 customers, mostly high-frequency trading firms that are paying $60,000 to $100,000 a month.

McGurn said Truth Social is in conversations to sign up cloud computing companies, large news organizations, and developers of large language models. The company plans to eventually offer the Truth API to retail investors, he said.

The company's press release that announced Truth API said that "markets already move on Truth Social posts" and that the service will become a significant, ongoing source of revenue. "Truth API is designed for organizations most impacted by the cost of a delay in information. This includes high-frequency and algorithmic trading firms that require a low-latency, machine-readable feed rather than manual tracking," the company said.

Lawsuit alleges violation of 1st and 5th Amendments

The lawsuit argues that Truth API imposes an impermissible burden on access to Trump's public announcements.

"The First Amendment guarantees equal access to the President’s public announcements, and even content-neutral burdens on that access must be narrowly tailored to serve a significant government interest," the lawsuit said. "There is no legitimate interest, let alone a significant one, in permitting President Trump to profit from selling government information. Similarly, the Fifth Amendment prohibits charging unreasonable sums that cannot be justified to offset the cost of the government benefit, and granting preferential access to crucial government information for arbitrary and irrational reasons, as is the case here."

The lawsuit said Truth Social appears set on making archived posts impossible to access without an API subscription. It pointed to a McGurn quote in which he said, “We’re going to create a lot of friction for those folks that aren’t coming to us directly.” This shows that Trump Media plans to disrupt web-scraping tools and ensure that users must subscribe to Truth API to access deleted or edited posts that are no longer available to the public, the lawsuit said.

The Intercept and the Freedom of the Press Foundation are both nonprofits and said they will be harmed by the Truth Social scheme. "Both face indefinitely delayed access to the President’s latest posts, and face permanent bars to the President’s archived posts, making it harder for both organizations to do their jobs," the lawsuit said.

We contacted the White House today and will update this article if it provides any comment.

This article was updated to correct the amount of Trump Media & Technology Group's net loss.

Read full article

Comments

When you submit a pull request, there are two places you can use to help explain what you are doing and why you are doing it. One is the pull request description, and another is the code you are modifying. And it’s important to understand the difference between them.

The pull request is where you justify why your change should be accepted. In the title, you spell out the problem you are fixing or the feature you are adding.

Add support for polarity reversal

Fix crash when polarity changes

In a large code base, you may need to be a little more specific.

Add support for widget polarity reversal

Fix widget crash when polarity changes twice in a short time

When somebody is chasing down a regression, they are going to be looking over all of the PRs that went into the branch recently, and having a good title will make it easier for them to identify which changes are likely to be a source of the problem.

For example, if somebody is investigating a doodad crash, they may look into “Add support for widget polarity reversal” because their doodad uses widgets, and maybe the problem is caused by a reverse-polarity widget that their doodad isn’t handling. On the other hand, they can pay less attention to the fix for the crash when widget polarity changes because that’s unlikely to be the reason the doodad is crashing. And if their doodad doesn’t use widgets at all, they may just skip over both of them.

If the PR had used the original titles of “Add support for polarity reversal”, without any mention of widgets, then a team investigating a regression in gadgets would have to dig into the PR (because gadgets also have polarity), only to realize that it’s about widget polarity, not gadget polarity.

The description of the PR talks about the source of the problem and how you fixed and validated it. This is point-in-time information where you justify to your reviewer why the change is needed and why your particular implementation of the change is correct. Discuss alternative designs and why they were rejected (e.g. because they were too risky). Show before-and-after screen shots showing that the problem is fixed. Confirm that associated paperwork has been completed, like unit tests. There might be standard paperwork for this, such as a “checkin template”. (It is often the case that the closer a project comes to release, the more stringent the paperwork. For example, late in the product cycle, you may need to demonstrate that the release management team has deemed that the bug meets the bug bar.)

In other words, the PR description is a point in time statement, providing information that is relevant to the code review itself. It is an exercise in persuasive writing: You are trying to convince the approver that your change should be accepted.

Comments in the code are for talking about the code itself. What is the correct way to call this function? Does it have specific prerequisites? This information is durable: It is information that remains useful even after the pull request completes.

Okay, so let’s do an exercise: I’m going to provide some text, and you tell me where it goes. These are all actual comments (suitably redacted) from PRs I have reviewed.

I have checked all calls to the function, and this was the only one that passed the wrong flag.

This goes into the pull request description. It is justifying why your change is correct, and in particular, it’s answering a question that a reviewer is likely to ask: “It’s great that you’re fixing this one caller of the function, but are there other callers that make the same mistake?” Putting this comment in the code itself would be wrong because the claim is valid only at the time the pull request is made. After the pull request, somebody might add a new call to the function that passes the wrong flag, and it is not true that you validated that new caller.

The JSON schema accepted by this function is documented 〈here〉.

This goes into the code. It is explaining how to use the function correctly. This information is important not just at the time you submit the pull request but also for an indefinite period of time in the future. (At least, until you change the function or the schema.)

The Doodad component will take advantage of polarity reversal.

This goes into the pull request description. It is justifying why you need to implement polarity reversal today. If you put this in the code, the future tense suggests that we are still waiting for Doodad. And future changes to the Doodad might cause them to stop relying on polarity reversal; when they do that, they are unlikely to come and update this comment in somebody else’s component. The comment also suggests that if you confirm with the Doodad team that they don’t need polarity reversal any more, it is safe to remove support for polarity reversal, which might not be the case if other components started using the feature as well.

Still, knowing that Doodad is the intended audience for the feature is worth noting for posterity.

// Polarity reversal was initially added for the benefit of
// the Doodad component.

Bonus chatter: Another thing to consider when making code comments is that the code comment needs to make sense even without the PR description. Suppose you are writing a function with the intention of deprecating an older function that it is replacing. Don’t add this comment to the new function:

// When all clients have migrated to the new function, keep this.

This makes no sense to someone who is seeing the comment without having also seen (and remembered) the PR that introduced it. It sounds like the comment is saying, “When X happens, take no action.”

What you should do is put a comment on the old function:

// When all clients have migrated to the new function, delete this function.

The post The comments that go into code versus those that go into the pull request description appeared first on The Old New Thing.